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ECRAN DE VISUALISATION SUSCEPTIBLE D'ETRE SOUMIS A UNE 

PROCEDURE DE DEFILEMENT 

DESCRIPTION 

5 DOMAINS TECHNIQUE 

La present e invention concerne un procSde 
d'affichage d'un document, par exemple vine page HTML 
("Hypertext mark-up language") , sur un Scran de 
visualisation susceptible d'Stre sourais h une procedure 
10 de defilement ("scrolling"), par exemple sur ion 6cran 
de television numSrique. 

ETAT DE LA TECHNIQUE ANTERIEURE 

Le domaine de l 1 invention est* notamment 
celui de l'aff ichage de pages HTML, comme dScrit -dans 

15 la demande de brevet EP 1 164 499. 

Une version de la norme HTML ("HTML 4.01 
Specification W3C Recommendation 24 dScembre 1999") 
peut §tre trouvee a 1 1 adresse Internet suivante 
http://www.w3 .org/TR/l999/REC-htmT401-1999 1224 

20 Une page HTML est un document qui peut Stre 

interprets par un programme de lecture pour produire 
une sortie visuelle, et e vent ue 1 1 ement audio, sur un 
moniteur d'ordinateur ou sur un Scran de tSlSvision. 
Une page HTML present Se sur un ecran est constitute 

25 habitue 11 ement d'un document principal et de documents 
secondaires pouvant contenir des SISments graphiques, 
sonores ou du code source. 

Af in de tenir compte de cette page HTML, 
ces Elements sont charges,, stockes en mSmoire et 

3 0 traites par un moteur HTML. La representation de. cette 
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page est stockee dans une memoire graphique pour 
af f ichage . 

Un moteur HTML est une application 
interactive permettant de visualiser des documents 
5 hypertexte et multimedia accessibles au travers du 
reseau Internet. II permet egalement d 1 envoyer et de 
recevoir du courrier electronique et de consulter des 
serveurs dits "news" . 

Dans le domaine de la television numerique 

10 une telle application interactive est pilotee par 
1 'utilisateur au moyen d'une teiecommande ou §. l'aide 
d'un clavier infrarouge. L 1 application peut, en effet, 
integrer tme interface de substitution permettant k 
1 'utilisateur d'effectuer toutes les saisies de texte 

15 ou autres avec seulement la teiecommande. L'aff ichage 
des documents est realise sur I'ecran. 

La recuperation des documents sur le reseau 
Internet s'effectue par 1 1 intermediaire de requites sur 
des serveurs particuliers . Dans le domaine de la 

2 0 television numerique cette operation peut §tre 
asymetrique. En effet, la requite et le document ne 
transitent pas necessairement par le mSme milieu : La 
requ§te peut Stre effectuee par le reseau teiephonique 
via un modem, et le document revenir soit par 

25 l'antenne, c'est-a-dire par emission du satellite, soit 
par le modem. L' utilisateur peut alors choisir le type 
de retour. 

Le contenu d f une page HTML peut exceder 
l'espace disponible sur le moniteur ou sur I'ecran de 
30 television. Dans ce cas le moniteur ou I'ecran de 
television n'affiche qu'une partie de la page HTML. 
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L f utilisateur peut alors faire dSfiler l'affichage pour 
avoir un apergu des parties restantes de la page HTML. 

Aprds defilement, la nouvelle partie 
visible du document HTML doit Stre affich^e. Chaque 
5 61Sment graphique en intersection avec la nouvelle 
partie visible doit Stre dessine ou redessin£. 

Le defilement d'un document est couramment 
r£alis6 de plusieurs fagons. La maniere la plus simple 
est l'affichage sans preparation prealable dans une 

10 m^moire graphique tampon, c'est §l dire en dessinant 
directement dans la fenStre affich£e a ricran. En cas 
de defilement du document, le contenu de la fenetre 
restant tou jours visible est deplace par une copie 
massive & sa nouvelle position dans la fenetre. La 

15 bande restante, nouvellement apparue, est affichee en 
redessinant individuellement chaque objet graphique. Ce 
procede a comme inconvenient, lorsque le systSme 
graphique est lent, de voir se composer progress ivement 
le dessin de chacun des objets graphiques. 

2 0 Pour remedier a ce problSme, une solution 

utilisee est de preparer la partie du document. & 
afficher dans une m^moire graphique tampon comme par 
exemple un pixmap et d 1 afficher en une fois le contenu 
de ce pixmap dans, la fen§tre visible. Ici deux 

25 techniques sont utilis£es. La premidre consiste & ne 
couvrir par cette memoire tampon que la zone visible du 
document. Dans ce cas, lorsqu'un defilement est demand^ 
la nouvelle portion visible du document est pr6par£e 
dans la memoire tampon et lorsque celle-ci est pr§te, 

30 elle est affichee (technique appeiee "double- 
buffering"). La seconde consiste a couvrir 
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1 ' integralite du document avec une m^moire graphique 
tampon, de preparer 1 1 integralite du document et de 
1'afficher au fur et & mesure des besoins . 

Les probl^mes majeurs de ces deux 
5 techniques sont que, pour la premidre, l'affichage est 
prepare sur demande explicite de defilement. Par 
consequent, entre la demande et le defilement effectif 
il peut se passer un certain temps dSsagr^able pour 
1 f utilisateur, le defilement n'etant pas fluide. Pour 

10 la seconde, si le probleme de temps d'attente n'existe 
pas, elle peut necessiter tine grande quantity de 
memoire graphique puisque celle-ci est liee & la taille 
de documents. Sur le r£seau internet, la taille des 
documents n'est pas limitee et la quantite de memoire 

15 graphique n€cessaire pour utiliser cette seconde 
technique peut €tre considerable. 

Une telle solution n'est pas, non plus, 
adaptee II l'affichage d'un decodeur parce que celui-ci 
necessite une memoire importante pour stocker les 

20 dormees pixmap qui sont calcuiees avant l'affichage. 
Or, la capacite memoire d'un decodeur de television, est 
limitee. Elle est par exemple de l'ordre de 2 
megaoctets de memoire graphique. Elle est done 
nettement plus limitee que celle d ! un ordinateur qui 

25 peut §tre de 32 megaoctets, ou 64 megaoctets... 

L 1 invention a pour object if de resoudre un 
tel probleme, c'est-&-dire d'offrir un defilement 
fluide d'un document dans un contexte de memoire 
limitee, ce document pouvant par exemple etre une page 

30 HTML . * 
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EXPOSE DE L' INVENTION 

La pr6sente invention concerne un procede 
d 1 af fichage d"un document sur un 6cran de visualisation 
susceptible d'etre soumis S. une procedure de 
5 defilement, caract€ris§ en ce qu'il comprend les etapes 
suivantes : 

- une £tape d 1 attribution au document d*une 
quant ite de memoire graphique pour creer une m^moire 
tampon de la partie visible du document et des zones 

10 les plus proches de cette partie visible appelees 
" bande s d 1 ant i c ipat i on " , 

- \ine Stape de calcul et de decoupage en 
pixmaps de cette memoire en f one t ion de la taille du 
document, de la partie visible, et de celles des bandes 

15 d 1 anticipation, 

- une 6tape, de positionnement relatif de 
ces pixmaps par rapport au document complet et sa 
partie visible, 

- une Stape, realisable en tache de fond, 
20 de remplissage du contenu des pixmaps avec un syst^me 

de priority en fonction de la proximite du pixmap par 

rapport & la zone visible, 

lorsque le document est soumis & tine 

procedure d f af fichage ou £ un defilement, une Stape de 
25 recopie du contenu des pixmaps dans la fen§tre 

d f af fichage avec prialablement si necessaire une 6tape 

forgant la mise a jour des pixmaps concernes par 

l»af fichage si I'Stape precedent e ne l'a pas terminee, 

et retour & l'^tape de positionnement 
30 relatif des pixmaps par rapport au document en fonction 

de la nouvelle position de la partie visible. 
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Avantageusement en cas de defilement 
horizontal et vertical, les bandes d' anticipation 
comportent au minimum une colonne de pixmaps k droite 
et a gauche de la fen€tre visible ainsi qu'une ligne de 
5 pixmaps en bas et en haut, sauf dans le cas ou la 
fen§tre visible approche le bord du document. Les 
pixmaps sont d£coup6s en rectangles qui sont des sines 
success ivement a chaque appel d'une tache de fond. 

Le remplissage d'un pixmap s^l est de 
10 grande taille peut §tre long et bloquer le systeme le 
temps de 1» operation. Le remplissage des pixmaps par 
rectangles de petites tailles permet de diluer 
l 1 operation de remplissage parmi les autres traitements 
du systdme, et pouvoir repondre rapidement a 
15 1 'utilisateur si n^cessaire. 

La tache de fond a £galement pour f one t ion 
de construire la zone d 1 anticipation. 

A chaque appel de cette tache de fond, le 
processus est le suivant : 
20 - reorganisation eventuelle des pixmaps si 

un defilement a £te effectue, 

- s ' il n'y a pas eu de repositionnement des 
pixmaps, dessin du premier rectangle d'un pixmap 
determine en fonction d'un critdre d' eloignement de la 
25 zone visible du document 

Avantageusement le proc€d6 de 1' invent ion 
utilise un m^canisme de synchronisation permettant le 
for<?age eventuel des donnees Sl afficher dans les 
pixmaps . 
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Un dessin immediat est r£alis£ dans deux 

cas : 

lorsqu'un Svenement "expose" oblige it 
dessiner une partie de la fenStre d 1 aff ichage alors que 
5 cette partie n ! est pas encore dessin^e dans les bandes 
d 1 ant i c ipa t ion , 

- lorsqu'un element du document ■ est modifi§ 
graphiquement dans la fenetre d f aff ichage. 

Le procede de 1 1 invention peut §tre 
10 notamment utilise pour l'aff ichage d'un document HTML, 
et/ou pour un d£codeur de television numerique. 

BREVE DESCRIPTION DES DESSINS 

La figure 1 illustre la visualisation de la 
zone d 1 anticipation selon le procede de 1' invention. 

15 La figure 2 illustre un exemple de 

deplacement de la zone d 1 anticipation. 

La figure 3 illustre le mecanisme de 
synchronisation, lorsque une partie des pixmaps n'est 
pas remplie et qu'un aff ichage est demande. 

20 La figure 4 illustre la constitution d'une 

arbor escence de sous -fen§t res dans un exemple de mise 
en ceuvre du procede de l 1 invention. 

La figure 5 illustre l 1 aff ichage de 
1 f arborescence representee sur la figure 4 . 

25 Les figures 6 et 7 illustrent, chacune, un 

document HTML aprds mise en page selon le procede de 
l 1 invention ; la largeur complete du document pouvant 
§tre couverte avec les pixmaps pour la figure 7, alors 
que pour la figure 6 ce n'est pas possible. 



30 
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EXPOSE DETAILLE DE MODES DE REALISATION PARTICULIERS 

Le procede, selon 1 'invention, d'affichage 
d' un document , par exemple une page HTML, sur un ecran 
de visualisation susceptible d'etre soumis a une 
5 procedure de defilement consiste k d§couper ce document 
en zones pouvant Stre couvertes par des pixmaps dont la 
taille est fonction de la taille de la zone de 
visualisation, et a pr£voir une zone d 1 anticipation 
partie du document reellement couverte par des pixmaps. 
10 Cette zone d 1 anticipation forme une matrice 

de pixmaps, couvrant du document, la partie visible et 
les bandes les plus proches autour de cette partie 
visible, de manidre k preparer le contenu de la partie 
visible et les zones prochainement visibles en cas de 
15 defilement du document. 

La zone d 1 anticipation a comme . finalite 
d f ameiiorer le rendu visuel des operations de redessin 
d'une partie du document. En effet, dans la plupart des 
cas, une copie de la zone d 1 anticipation dans la 
2 0 fen^tre d'affichage s'avdre suffisante. 

La figure 1 represente une telle zone 
d 1 anticipation 10, form6e ici de 18 lignes et 12 
colormes de pixmaps 13, la fenStre visible 11 ou le 
document 12 est visualise. 
2 5 On constate 1 1 inclusion hierarchique des 

trois zones ainsi formees, le document 12 incluant la 
zone d 1 anticipation 10, cette derni^re contenant la 
fen§tre visible 11 du document.. La zone d 1 anticipation 
peut trds bien recouvrir en largeur ou en hauteur le 
30 document si l'espace disponible est suffisant, comme le 
montre 1 1 illustration de la figure 7. 
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La figure 2 montre Involution- de la zone 
d ! anticipation 10 suite a une operation de defilement 
de l'affichage du document 12 vers le bas. Cette 
operation de defilement entralne un deplacement de la 
5 premidre ligne en bas de la zone d 1 anticipation. Cette 
ligne doit alors Stre redessin6e. 

La zone d' anticipation comporte au minimum 
vine colonne de zones pixmap & droite et §l gauche de la 
fen§tre visible ainsi qu'une ligne de zones pixmap en 
10 bas et en haut, sauf dans, le cas ou la fenStre visible 
11 approche le bord du document 12. Si cette rdgle 
- n'est pas respectee la suite d'un defilement, la zone 
d 1 anticipation se d^place de manidre £ r^tablir celle- 
ci. 

15 Pour ne pas risquer de bloquer 

1 'application pendant plusieurs secondes, le dessin de 
la zone d 1 anticipation, suite at sa creation ou a un 
defilement, est tel qu'une tache de fond effectue ce 
dessin en plusieurs Stapes : les zones pixmaps sont 

2 0 formSes en rectangles qui sont dessinSs successivement 

a chaque appel de la tache de fond. 

Cette tache de fond a egalement pour 
fonction de construire la zone d 1 anticipation. 

A chaque appel de cette tache de fond, le 
25 processus est le suivant : 

- deplacement si necessaire de la zone 
d 1 anticipation par permutation de lignes ou de colonnes 
en pixmaps, 

- si la zone * d' anticipation est 

3 0 correctement posit ionn6e, dessin du premier rectangle 

d'un pixmap de la zone d 1 anticipation. 
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Si le pixmap a afficher n'est pas pr§t au 
moment de l'affichage, un mecanisme de synchronisation 
permet de forcer le raf raichissement des donnees a 
afficher dans les pixmaps . 
5 Un dessin imm6diat est realise dans deux 

cas : 

- lorsqu'un evenement "expose" oblige §l 
dessiner une partie de la fen§tre d'affichage alors que 
cette partie n'est pas encore dessinee dans la zone 

10 d' anticipation, 

- lorsqu'un element du document est modifi6 
graphiquement dans la fen§tre d'affichage. 

Ces deux cas correspondent respectivement £ 
un afflux de nouvelles donnees concernant une image et 
15 au traitement du focus qui modifie le dessin d'un 
element de 1 1 image . 

Dans ces deux cas tous les rectangles en 
attente ayant une intersection commune avec la zone a 
dessiner sont dessin^s. La figure 3 repr<Ssente les 
20 Elements qui composent alors la zone d 1 anticipation : 

- les rectangles dejS. dessin§s 20, 

- les rectangles non dessin^s 21, 

- la fenStre d'affichage 22, 

- le rectangle 23 a dessiner suite & un 
2 5 evenement " expo s e " , 

- les rectangles non dessin^s 24 qui sont 
. en intereaction avec le rectangle 23, le dessin de leur 

contenu 6tant force par la synchronisation. 

30 
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Mise en oeuvre du procede de 1 1 invention dans une 
application HTML 

On va, present, consid§rer un exemple de 
mise en oeuvre du procede de 1' invention, dans une 
5 application HTML dans un decodeur. 

La premiere operation consiste §l repartir 
la memoire graphique utilisable dans une arborescence 
de sous-f enetres (ou "frames" HTML) . 

La quantite de memoire graphique disponible 
10 pour creer les pixmaps est limit^e au niveau du 
decodeur. Pour garantir un bon f onctionnement des 
autres applications fonctionnant en meme temps que le 
moteur HTML, seule une partie de cette memoire est 
utilis£e par le moteur HTML pour creer les zones 
15 d 1 anticipation. La quantite de memoire disponible est 
d^finie au lancement du moteur HTML. Dans le cas oil 
plusieurs documents deroulants sont visibles 
simultanement a l'6cran (cas des sous-f enStres ou 
"frames" HTML), il faut que chaque document puisse 
20 prof iter du mecanisme de d^roulement fluide que 
const itue le proced^ de I 1 invention. La quantity de 
memoire disponible doit done §tre repartie sur tous les 
documents visibles simultanement . 

Le procede de 1 1 invention, ne conceme que 
25 des documents deroulants. Les documents declarant des 
sous-f enetres HTML ne peuvent jamais §tre deroulants . 
Seuls les documents feuilles d'une arborescence de 
sous-fen§tres sont susceptibles d'etre deroulants, et 
sont done utilisateurs potentiels du proc£d£ de 
30 l 1 invention. Ainsi, la somme des parties visibles des 
documents HTML susceptible d'§tre deroulante couvre 
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exactement la surface reservee a l'affichage du moteur 
HTML. Cette propriety est utilisee pour garantir une 
utilisation du proc6d6 de 1 1 invention pour chaque 
document f eui lie. 
5 Be moteur HTML r€partit proportionnellement 

la memoire graphique, en fonction de la surface de 

chaque sous - f en§t re : 

M represente la quant ite de memoire 

graphique r^serv^e au moteur HTML, 
10 - Wm & Bm : la taille en pixels de la 

fen§tre d'affichage du moteur HTML, 

- W£ & Bf : la taille en pixels d'une sous- 

fenetre quelconque. 

La quantite de memoire graphique utilisable 
15 par cette sous-fen§tre pour cr6er ses zones 
d ! anticipation est proportionnelle k la surface : 

Mf m Af* (Wf*Hf) / (Wm*Hm) 

Un exemple d'arborescence de sous-f enStre, 
dans laquelle chaque case constitue un document HTML, 
20 est illustr^ sur la figure 4. On a ainsi un document 
racine, par exemple de 600 x 400 pixels, dont d^coule 
un document Frame 1, par exemple de 600 x 100 pixels, 
et un document Frame 2, par exemple de 600 x 300 
pixels, dont decoule un document Frame 2-1, par exemple 
25 de 200 x 300 pixels et un document Frame 2-2, par 
exemple de 400 x 300 pixels. 

L ! affichage d'une telle arborescence donne 
le r£sultat illustre sur la figure 5. 

Dans un tel exemple la. repartition de la 
3 0 memoire graphique peut §tre realis^e de la fa<?on 
suivante, avec, M 1.920 Koctets : 
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- Document racine (declaration de frames)- 

0 octet 

- "Frame 1" (document f euille) - 480 Koctets 

- "Frame 2" (declaration de " frames ")= 0 

5 octet 

"Frame 2.1" (document f euille) = 480 

Koctets 

"Frame 2,2" (document f euille) = 960 

Koctets 

10 L* operation suivante est un probl^me de 

determination de granular ite des pixmaps : pour une 
quantite de m^moire graphique disponible pour un 
document il faut determiner quelle est la taille et la 
granularity des pixmaps qui va permettre le bon 

15 fonctionnement du systeme. L'objectif est de garantir 
au moins un pas de defilement, d f anticipation du 
mouvement de part et d 1 autre de la zone visible, et 
d 1 avoir au moins une rang£e de pixmaps pouvant Stre 
d£plac£e d'un c6te ou de l 1 autre. 

20 La figure 6 represent e ion document HTML 12 

complet apr^s la mise en page, la partie couverte par 
les pixmaps 13 et la partie visible 11. Ce document 12 
est susceptible & la fois d f avoir un defilement 
horizontal et un defilement vertical. 

25 Sur cette figure sont representes les 

parametres suivants : 

- Wd & Hd : largeur et hauteur en pixels du 
document complet aprSs mise en page, 

- Wf & Hf : largeur et hauteur en pixels de 
. 30 la partie visible du document (taille de la sous- 

f en^tre) , 
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- Wp & Hp : largeur et hauteur en pixels 

d'un pixmap, 

II existe d'autres paramdtres non 
representee sur cette figure : 
5 - Nx & Ny : nombre de pixmaps en horizontal 

ou en vertical, 

- Px & Py : bande d 1 anticipation garantie 
disponible en horizontal et en vertical de part et 
d'autre de la zone visible (cette bande d 1 anticipation 

10 correspond, au minimum, au pas de defilement) , 

- T : taille d'un pixel en octets (fonction 
du syst^me de codage des couleurs) , 

Mf : quant ite de m^moire graphique 
disponible pour les pixmaps associ^s au document. 

15 On considdre tout d'abord que le document 

12 peut §tre d^roule horizontalement et verticalement 
et que la quantity de memoire graphique est 
insuffisante pour couvrir 1 1 int€gralite de celui-ci 
avec des pixmaps aussi bien en horizontal qu'en 

2 0 vertical. 

Pour pouvoir garantir & la fois la 
permutation des pixmaps et 1 1 existence d'une bande 
d 1 anticipation garantie de chaque cote, on doit 
respecter les inegalites suivantes : 
25 - 2 Px + Wf < Wp (2toc-l)+l (1) 

avec Nx > 1 

- 2 Py + Hf < Hp (tfy-l)+l (2) 
avec Ny > 1 
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La limitation m^moire impose egalement une 
contrainte. La somme des pixmaps ne doit pas depasser 
la quant ite de memoir e reservee : 

Mf > Nx*Ny*Wp*Hp*T (3) 

5 Le nombre d 1 equations est encore 

insuffisant pour determiner le nombre et la taille des 

pixmaps. Aussi, on opte pour certaines conditions 

particuli^res : 

Px, la zone d 1 anticipation horizontale 

10 garantie, est definie comme egale au pas de defilement 

horizontal . 

Py, la zone d 1 anticipation verticale 
garantie, est definie comme egale au pas de defilement 
vertical . 

15 - Px = OL Wf : le pas horizontal de 

defilement est proportionnel & la largeur d'affichage 
du document . 

- Py - 0L Hf : le pas vertical de defilement 
est proportionnel & la hauteur d'affichage du document 
20 avec 0 < 0L < 1, 0L etant une constante du moteur HTML 
(contrainte garantissant que 1 1 integrality du document 
peut §tre consul te par un deroulement pas pas) . 

{Wp*Nx) *H£ = (ffp*!^)*^ (4) : les 
dimensions de la zone d 1 anticipation sont 
25 proportionnelles aux dimensions de la zone d'affichage. 

On determine la taille et le nombre de 
pixmaps en horizontal en utilisant les equations (3) et 
(4) et en considerant que la capacite maximum de la 
memoire graphique doit Stre utilisee. On obtient le 
30 rSsultat suivant : 
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W p *Nx = ((JCe*W£)/(J5r£*T)) 1/a (5) 
o\l JVp*^ correspond 3. la largeur en pixel de la zone 
d 1 anticipation. 

En utilisant les Equations (1) et (5.) , on 
5 obtient la largeur maximum d'un pixmap : 

WW - ((M£*W£) / (H£*T)) x/2 +l-(2 0C + 1)W£ 
En divisant la largeur de la zone 
d 1 anticipation (Wp*Nx) de (5) par la largeur maximum 
d'un pixmap Wp max et en arrondissant a la valeur entiere 
10 sup^rieure, on obtient le nombre de zones pixmap 
minimum en largeur NXmin. 

Pour toute les valeurs de Nx > Nx m±n , , le 
. bon f onctionnement du procede de 1 ' invention est 
assuri. Dans la mise en oeuvre du moteur HTML, c'est la 
15 valeur Nx^ n qui est retenue pour le d^coupage. En 
effet, au niveau du decodeur, le nombre de pixmaps 
pouvant Stre cr6e est limite. On garantit ainsi au 
maximum la possibility d'utiliser le proc6d§ de 
l 1 invention et on evite done d'atteindre une telle 
20 valeur critique. 

La largeur reelle d'un pixmap Wp est 
obtenue en divisant la largeur de la zone 
d 1 anticipation {WP*Nx) de (5) par le nombre de pixmaps 
retenu Nx^n arrondi au nombre entier inf^rieur. 
2 5 Dans 1 1 exemple de la " Frame 2 . 2 " , en 

prenant un coefficient <X a 10% et T - 4 octets, les 
resultats obtenus sont les suivants : 

- NX m 7 

- Wp » 8 0 pixels 
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La determination de la taille et du nombre 
de pixmaps en vertical est rSalisee de la m§me fa<jon 
qu'en horizontal. 

Dans 1' example considere, les resultats 
5 obtenus pour "Frame 2.2" sont les suivants : 

- Ny = 7 

- Hp = 60 pixels 

Avec cette mSthode de calcul, la 
granularity des pixmaps est toujours la meme en 

10 horizontal et en vertical. 

Dans la mise en oeuvre du decodeur, il faut 
tenir compte d f un paramdtre supplement aire : les 
pixmaps cr£6s doivent toujours avoir des dimensions 
multiples de 8 pixels. Par consequent, apr£s avoir 

15 determine la taille de chaque pixmap et le nombre de 
pixmaps dans une direction, en arrondissant cette 
taille au multiple de 8 inferieur, on verifie que 
1 'equation (1) ou (2) selon la premiere direction 
traitee) est toujours validee. Si ce n'est plus le cas, 

20 il faut augmenter de 1 la granularite des pixmaps et 
recalculer la nouvelle taille d'un pixmap. 

Avec ces arrondis, une partie de la memoire 
reservee pour le calcul dans une direction peut n'Stre 
plus totalement utilisee. Ce trop plein de memoire est 

25 alors reporte sur l 1 autre direction avant de calculer 
la taille et le nombre de pixmaps. Dans ces nouvelles 
conditions, la granularite horizontale et verticale 
peuvent devenir differente. 

Comme illustre sur la figure 7, dans le cas 

3 0 ou Wp*Nx >. Wd, il est possible de couvrir toute la 
largeur du document avec des pixmaps. Il n'y a done pas 
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besoin d'un mecanisme cie permutation horizontal. La 
determination du nombre et de la granularite des 
pixmaps est differente. Le trop plein de m^moire 
graphique disponible au niveau du defilement horizontal 
5 est affects au defilement vertical. La largeur des 
pixmaps est alors la largeur maximum de creation d'un 
pixmap dans un decodeur. 
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REVINDICATIONS 

1. Proc£d£ d'affichage d ! un document (12) 
sur un ecran de visualisation pouvant Stre soumis a une 
5 procedure de defilement, caract6ris6 en ce qu'il 
comprend les etapes suivantes : 

- une 6tape d' attribution au document d'une 
quant ite de memoire graphique pour creer une memo ire 
tampon de la partie visible du document et des zones 

10 les plus proches de cette partie visible appel^es 
bandes d 1 anticipation (10), 

- une etape de calcul et de d^coupage en 
pixmaps de cette memoire en fonction de la taille du 
document, de la partie visible, et de celles des bandes 

15 d' anticipation (10), 

- une <§tape de positionnement relatif de 
ces pixmaps par rapport au document complet et sa 
partie visible, 

- une Stape, realisable en tclche de fond, 
20 de remplissage du contenu des pixmaps avec un syst^me 

de priorite en fonction de la proximite du pixmap par 

rapport S la zone visible, 

lorsque le document est soumis a une 

procedure d'affichage ou a un defilement, une etape de 
25 recopie du contenu des pixmaps . dans la fen§tre 

d'affichage avec prealablement si necessaire une 6tape 

forgant la mise & jour des pixmaps concernes par 

l'affichage si l'^tape prSc^dente ne I'a pas termin^e, 

et retour a 1 1 etape de positionnement 
30 relatif des pixmaps par rapport aux documents en 

fonction de la nouvelle position de la partie visible. 
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2. Proc^de selon la revendication 1, dans 
lequel les bandes d 1 anticipations (10) comportent au 
minimum une colonne de pixmaps a droite et a gauche de 

5 la fen§tre visible (11) ainsi qu'une ligne de pixmaps 
en bas et en haut, sauf dans le cas ou la fenitre 
visible (11) approche le bord du document (12) . 

3. Proc£d£ selon la revendication 1, dans 
10 lequel les pixmaps (13) sont decoupes en rectangles qui 

sont dessinSs successivement & chaque appel d'une tache 
de fond . 

4 . Proc^de selon la revendication 3 , dans 
15 lequel la tache de fond a Sgalement pour fonction de 

construire les bandes d 1 anticipation (10) . 

5. ProcedS selon la revendication 3, dans 
lequel, Sl chaque appel de cette tache de fond, on a : 

20 - reorganisation £ventuelle des pixmaps si 

un defilement a ete effectu6, 

- s'il n f y pas eu de repositionnement des 
pixmaps, dessin du premier rectangle d'un pixmap 
determine en fonction d ! un critdre d' 61oignement de la 

25 zone visible du document, 

6. ProcedS selon la revendication 1, qui 
utilise un m^canisme de synchronisation permettant le 
forgage gventuel des donnSes afficher dans les 

30 pixmaps. 
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7. Proc6d£ selon la revendication 1, dans 
lequel un dessin immediat est realist dans deux cas : 

lorsqu'un evenement "expose" oblige a 
dessiner une partie de la fenetre d'affichage alors que 
5 cette partie n'est pas encore dessinee dans les bandes 
d 1 anticipation (10) , 

ou lorsqu'un element du document est 
modifi^ graphiquement dans la fenStre d*affichage. 

10 8. Utilisation du proc^de selon I'une 

quelconque des revendications prec^dentes pour 
l'affichage d'un document HTML. 

9. Utilisation du procede selon I 1 une 
15 quelconque des revendications 1 & 7 dans un d^codeur de 
television numerique. 
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